FIG. 1 of the accompanying drawings illustrates schematically a mobile network architecture including a General Packet Radio Service (GPRS) access network and an IP Multimedia Subsystem (IMS). The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP multimedia services over mobile communication networks. IP multimedia services can provide a dynamic combination of voice, video, messaging, data, etc. within the same session. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals. The Session Description Protocol (SDP), carried by SIP signals, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, the IMS allows operators and service providers to control user access to services and to charge users accordingly.
As shown in FIG. 1, managing of communications of user terminals (user equipment, UE; not shown in the figure) that connect to the network of FIG. 1 can be considered as held at three layers (or planes). The lowest layer (illustrated in the figure as “Connectivity Layer, 1”), is also referred to as the bearer or user plane, and provides the connectivity means through which signals are directed to/from UEs accessing the network. The entities within the connectivity layer 1 that connect a UE to a further network providing application services (e.g. allowing an IMS subscriber to access from his UE to IMS services provided by IMS network 3b) form a network that is referred to as an IP-Connectivity Access Network, IP-CAN. A GPRS network is an example of a IP-CAN network and, apart of the radio access nodes, includes various GPRS Support Nodes (GSNs), such as Gateway GPRS Support Nodes (GGSN) and Serving GPRS Support Nodes (SGSN). A GGSN (e.g. GGSN 2a) cooperates with one or more SGSNs, and acts as an interface between the GPRS backbone network and other networks (such as an IMS network). A middle layer (illustrated in the figure as “Control Layer, 4”) implements control functions relating to the signals held by the IP-CAN network. For example, in case of an IP-CAN network comprising GPRS, part of these functions can be implemented by SGSNs and GGSNs of said IP-CAN network, and relate to the processing of signals received from, or addressing to, a UE that connects through the IP-CAN network (e.g. bearer establishment, bearer termination, etc). At the top of a UE's communication there can be further servers managing high-layer aspects of said communication (illustrated in the figure by an “Application Layer, 6” comprising one or more “Application Servers, 7”).
In the illustrated example, the IMS subsystem 3 includes a core network 3a and a service network 3b. The IMS core network 3a includes nodes that send/receive signals to/from nodes in the IP-CAN network (e.g. via the GGSN 2a). In particular, the IMS 3 comprises network nodes (known as “Call Session Control Functions, CSCFs, which operate as SIP proxies , and which are arranged to communicate with nodes of an IP-CAN network that perform connectivity and control functions (e.g. with a GGSN, 2a). An example of such a kind of CSCF in a IMS is the so called Proxy-CSCF, P-CSCF.
The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF. Application Servers (AS) 7 can be provided for implementing some of IMS service functionality. For example, an AS 7 can receive and process signalling related to a UE (i.e. as received from an IP-CAN network to which said UE attaches) so as to control higher layer aspects of a service (e.g. divert an incoming call to a voice mail service, or forward it to a certain terminal, etc).
The 3GPP specification TS 23.203 (V9.3.0) discloses a Policy and Charging Control architecture (PCC). Among other functional nodes, it discloses the functionality of: the Policy and Charging Rules Function (PCRF), Policy and Charging Enforcement Function (PCEF) and Bearer Binding and Event Reporting Function (BBERF), which interact among them (through the so-called “Gx” and “Gxx” interfaces) so as to apply policy and charging rules to the data bearer(s) set up for a user terminal (UE). In short, a PCRF is a PCC rules decision node, whilst a PCEF or a BBERF are functional entities implemented in gateway nodes routing media of the related bearer(s) and enforcing said PCC rules; e.g. a GGSN or a Packet Data Network Gateway (PDN-GW, also referred herein as PGW) can implement PCEF functions.
FIGS. 2A to 2C of the accompanying drawings are taken from 3GPP specification TS 23.203, and show an overall PCC logical architecture; FIG. 2A is simplified for the case of non-roaming UEs. The architecture shown in FIG. 2 is envisaged for an Evolved Packet System (EPS) which is also adapted for interworking with nodes of legacy mobile packet systems. The EPS system referred in 3GPP TS 23.203, which incorporates PCC specific elements, is an example of an Internet Protocol Connectivity Access Network, IP-CAN. PCC has been specified for flow based charging and policy control of IP CANs (e.g. GPRS, I-WLAN, EPC, Fixed Broadband, etc.).
In particular, FIG. 2A illustrates an overall PCC logical architecture (non-roaming), and is derived from FIG. 5.1.1 of 3GPP TS 23.203; FIG. 2B illustrates an overall PCC architecture (roaming with home routed access), and is derived from FIG. 5.1.2 of 3GPP TS 23.203; and FIG. 2C illustrates an overall PCC architecture for roaming with PCEF in visited network (local breakout), and is derived from FIG. 5.1.3 of 3GPP TS 23.203.
In cellular telecommunication systems that employ dynamic Policy and Charging Control (PCC), such as 3GPP-based systems like the EPS and 2G/3G-GPRS or non-3GPP based systems like HRPD and WiMax, the PCEF interacts with the Online Charing System (OCS) over an interface known as the Gy interface. The PCEF also interacts with the PCRF over an interface known as the Gx interface. The BBERF performs so-called bearer management in the Access Network, and carries out event reporting to the PCRF over an interface known as the Gxx interface. The BBERF interacts with the PCEF via an interface known as the S5/S8 interface that is based on the Proxy Mobile IP (PMIP) protocol.
In the 3GPP PCC architecture [3GPP TS 23.203] an IP-CAN session is an association between a UE represented by an IPv4 and/or an IPv6 address, and UE identity information, if available, and a Packet Data Network (PDN) represented by a PDN identifier (e.g. an Access Point Name, APN). An IP-CAN session can incorporate one or more IP-CAN bearers. Support for multiple IP-CAN bearers per IP-CAN session is IP-CAN specific. Further on an IP-CAN session exists as long as UE IP addresses are established and announced to the IP network. There are different IP-CAN access types envisaged by the current PCC standards; for example 3GPP-EPS, 3GPP-GPRS, 3GPP2, xDSL, Wimax, etc.
In particular, the specification 3GPP TS 23.401 describes a particular case of the PCC network architecture of 3GPP TS 23.203 for the so-called “3GPP accesses” (GERAN/UTRAN/E-UTRAN—abbreviations for GSM EDGE Radio Access Network/Universal Terrestrial Radio Access Network/Evolved UTRAN), also referred as “3GPP-EPS”; and the specification 3GPP TS 23.402 describes a particular case of the PCC network architecture of 3GPP TS 23.203 for the so-called “non-3GPP accesses”.
An “IP-CAN domain” represents a set of access network entities which names and associated functions are dependent on the particular IP-CAN access type (IP connectivity access type). For example, an IP-CAN domain can include, among other: “e Node B” (eNB, or Evolved Node B), “Mobility Management Entity” (MME), “Serving Gateway” (SGW), “PDN Gateway” (PGW) and so on. In particular, a SGW is used to implement the BBERF functionality in case PMIP based S5/S8 is used, and a PGW uses to implement the PCEF functionality.
The PCC architecture defined in 3GPP TS 23.203 is intended to apply policy and charging control (PCC) in IP-CAN networks, such as Evolved Packet System (EPS) networks that includes both 3GPP accesses (GERAN/UTRAN/E-UTRAN) and Non-3GPP accesses, according to TS 23.401 and TS 23.402. PCC functionality is basically implemented by nodes of an IP-CAN network that perform connectivity and basic control functions (e.g. gateways such as SGW, PGW or GGSN implementing PCEF or BBERF functions) in cooperation with nodes implementing policy decision functions (i.e. nodes implementing PCEF functionality). Some of the PCC functionalities described by 3GPP TS 23.203 can also be achieved in cooperation with “Application Functions” AF (e.g. application servers 7 in FIG. 1) which communicate with a PCEF. An example of an “Application Function” AF is a P-CSCF of an IP Multimedia Subsystem IMS.
An EPS compliant architecture needs to support both PCEF and PCRF functionality to enable dynamic policy and charging control by means of installation of PCC rules on the IP-CAN session based on user (i.e. UE user) and service. For example, in case of 3GPP-EPS network, during E-UTRAN initial attach procedure of a UE, the PCEF initiates a IP-CAN control signalling session (e.g. a session according to DIAMETER protocol for the PDN connection between PCEF and PCRF. In addition in case of PMIP based S5/S8 interface, the BBERF must also setup a DIAMETER session for that PDN connection of the UE.
Referring to the simplified architecture for supporting Policy and Charging Control (PCC) functionalities as illustrated in FIG. 2A (a similar description would apply to FIGS. 2B and 2C), the PCRF 1A is a functional element that encompasses policy control decision and flow based charging control functionalities. The PCRF 1A provides network control regarding the service data flow detection, gating, QoS and flow based charging (except credit management) towards the PCEF 2A. The PCRF can receive session and media related information from an Application Function (AF) 3A and can also inform the AF of traffic plane events. The PCRF provisions PCC Rules to the PCEF 2A via the Gx reference point.
The PCEF 2A is a functional element that encompasses policy enforcement and flow based charging functionalities. This functional entity is located at a gateway node 4A of the network (e.g. GGSN in the GPRS case, and PDG in the WLAN case). The PCEF provides control over user plane traffic handling at the gateway 4A and in particular over the applied Quality of Service (QoS). It provides service data flow detection and counting as well as online and offline charging interactions, e.g. towards the OCS 5A and OFCS 6A. FIG. 2A also illustrates a Bearer Binding and Event Reporting Function (BBERF) and Subscriber Profile Repository.
The AF 3A is a functional element implementing applications for which a service is delivered to a user terminal (UE) The AF 3A controls IP bearer resources in order to satisfy the requirements of the service. One example of an AF 3A is a Proxy Call Service Control Function (P-CSCF) of an IP Multimedia Subsystem (IMS) core network. The AF 3A communicates with the PCRF 1A to transfer dynamic session information. This communication is performed using the Rx interface.
A packet data flow (such as an IP flow) is a set of data packets (e.g. IP packets) passing a routing node in a packet data network during a certain time interval, to or from the same endpoints. For example, a packet flow may be an IP flow, where each packet of the flow contains the same values of source IP address, source transport layer port (e.g. TCP), destination IP address and destination transport layer port.
When a User Equipment (UE) initiates a data session (e.g. an IP-CAN session), a packet data network address, such as an IP address, is assigned to it by an appropriate access gateway, e.g. the GGSN. The PCEF within the gateway provides this IP address, together with, for example, an NAI, IMSI, or MSISDN, to the PCRF which in turn downloads into the PCEF a set of policy rules to be applied to the data session. When the UE communicates with an AF, e.g. a P-CSCF in the case of an IMS service architecture, the AF provides session details to the PCRF. When the UE subsequently requests resources for the service provided by the AF, the PCRF downloads into the PCEF a further set of policy rules based on the session details provided by the AF.
The policy control features comprise gating control and QoS control. Gating control is applied by the PCEF (Policy and Charging Enforcement Function) on a per service data flow basis. To enable the PCRF gating control decisions, the AF (e.g. P-CSCF) has to report session events (e.g. session termination, modification) to the PCRF (Policy and Charging Rules Function). For example, session termination, in gating control, may trigger the blocking of packets or “closing the gate” [Policy and charging control architecture, 3GPP 23.203 V9.4.0].
In the PCC architecture, IP CAN session modification procedure is defined as set out in FIG. 3 of the accompanying drawings.
Referring to FIG. 3, in step 1, the AF (e.g. P-CSCF in the IM CN subsystem) may provide/revoke service information to the PCRF due to AF session signalling.
In step 5, the PCRF sends the Policy and Charging Rules Provision (PCC Rules, Event Trigger, Event Report) to the PCEF. And in step 6, the PCEF enforces the decision.
An example of IP CAN session modification is when there is an IMS session modification. That is, the P-CSCF (acting as AF) receives the SDP parameters defined by the originator within an SDP offer in SIP signalling, and it identifies the relevant changes in the SDP. So the P-CSCF sends to the PCRF a Diameter AAR for an existing Diameter session and includes the derived updated service information. The PCRF stores the received updated session information and identifies the affected established IP-CAN Session(s), and sends information to the PCEF so that the PCEF can enforce the update [Policy and Charging Control signalling flows and QoS parameter mapping, 3GPP 29.213 V8.4.0].
In additional to the gating using the PCC architecture, gating can be done in additional intermediate nodes in the IMS network, such as the IBCF/TrGW and the IMS ALG/IMS AGW [IP Multimedia Subsystem (IMS), stage 2, 3GPP 23.228 V9.0.0]. The interaction with the GW for the gating part is done similar to PCC, i.e., when a SDP answer/200 OK is received, the controlling function (IBCF or IMS ALG) instructs the media gate in the media node (TrGW or IMS AGW) to open up for the new media.
The present applicant has identified the following technical issue with the above-described arrangements.
As specified in [Policy and Charging Control signalling flows and QoS parameter mapping, 3GPP 29.213 V8.4.0], the enabling of IP Flows procedure is triggered by the P-CSCF receiving any 2xx success response to an INVITE request or a 2xx success response to an UPDATE request within a confirmed dialogue (in both cases a 200 OK response is usually received). Only when receiving such responses, the PCRF will interact with PCEF to open/close gate for IP flow(s). Similar applies for the IBCF/TrGWs and IMS ALG/IMS AGW, the interaction with the GW to open (or change) the gate is done when the 200 OK is received.
This mechanism can be problematic with Access Transfer as specified in [IP Multimedia Subsystem (IMS) Service Continuity, 3GPP 23.237 V9.3.0]. Access Transfer is transfer at the IMS-level of one or more media paths of an ongoing IMS session on one UE between Packet Switched (PS) to Circuit Switched (CS) access; or transfer at the IMS-level of both the signalling and the media path of an ongoing IMS session on a UE between different IP-CANs. It includes PS-CS access transfer (both directions in some cases) and PS-PS access transfer. If there is a change of IP address for the UE, during the access transfer the media path will be broken. For example, refer to the call flow of FIG. 4 of the accompanying drawings [IP Multimedia Subsystem (IMS) Service Continuity; Stage 3, 3GPP 24.237 V9.2.0].
Referring to FIG. 4, at step 10, the 200 OK will first reach the P-CSCF of UE B (not shown in the figure). The P-CSCF of UE B will then inform the corresponding PCRF with the updated SDP information. And accordingly the PCRF will control the gating in the PCEF (e.g. GGSN). From now on, the IP flows between UE A and UE B is broken, as PCEF has been ordered to gate the IP flows from the new IP address of UE A, while UE A has not yet started to use this new IP address as it has not yet received the SDP answer from UE B.
Any intermediate gating, such as IBCF/TrGW etc, will not update their gates until the SDP answer is received. This means that the network may not be in synch between the different gating functions in originating and terminating networks. Some still allows the media to flow to/from the old IP address, some to/from the new IP address.
When the 200 OK reaches the P-CSCF of the UE A (step 15), it informs the corresponding PCRF, and PCRF controls the gating in the PCEF for UE A. From now on, the IP flows between UE A and UE B resume, as only at this time, all gates in the network are in sync again.
It can be seen, if the two UEs are located in different networks, that the voice path break between step 10 and 15 can be significant, and be longer than 300 ms. Hence it is audible and impacts the perceived service quality.
A more complete view of the situation is shown in FIG. 5 of the accompanying drawings.
There may be one or more Interconnection Border Control Function (IBCF) along the media path. Each IBCF will control a Transition Gateway (TrGW). The interface between IBCF and TrGW is Ix [Interconnection Border Control Functions (IBCF)—Transition Gateway (TrGW) interface, lx Interface; Stage 3, 3GPP 29.238 V9.2.0], which is based on H.248. When the media path changes, IBCF will need to change the gate in TrGW (not shown). H.248 has defined a service change method “Graceful” for taking a Termination out of service after a specified time of delay [Gateway control protocol: Version 2, ITU-T H.248.1]. However, this existing mechanism may need to be enhanced as well.
Similarly, the interface between P-CSCF (IMS ALG) and IMS AGW is Iq, which is also based on H.248 [IMS Application Level Gateway (IMS-ALG)—IMS Access Gateway (IMS-AGW); Iq Interface; Stage 3, 3GPP 29.334 V9.2.0].
It is desirable to address the above issue as identified and formulated by the present applicant.